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Dear Sir: 

As required under § 41.37(a), this brief is filed within two months of the Notice of 
Appeal filed in this case on September 2, 2008, and is in ftirtherance of said Notice of 
Appeal. The Notice of Appeal of September 2, 2008 was filed in response to the Examiner's 
second re-opening of prosecution with an office action of April 30, 2008. 

The fees required under § 41 .20(b)(2) are dealt with in the accompanying 
TRANSMITfAL OF APPEAL BRIEF. The fees required are only the difference in fees due 
to the PTO increase of fees on October 2, 2008. 
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I REAL PARTY IN INTEREST 

The real party in interest for this appeal is: 

Hewlett-Packard Development Company, L.P., a Texas Limited Partnership having 
its principal place of business in Houston, Texas. 

IL RELATED APPEALS, INTERFERENCES, AND JUDICIAL PROCEEDINGS 

Applicant respectfully notes that the following co-pending applications are or have 
been previously on appeal before the Board, which may have a bearing on the Board's 
decision in this appeal: 1) Application No. 10/147,249 ("the * 249 Application"); and 2) 
Application No. 09/880,632 (**the '632 Application"), 

The '249 Application has since been granted as U.S. Patent No, 7,437,451 with an 
issue date of October 14, 2008, An Appeal was filed for the '249 Application, but responsive 
to the Appeal Brief being filed in that application, the Examiner withdrew the rejections at 
issue and reopened prosecution. Accordingly, the appeal was not permitted to advance for 
consideration by the Board, and thus no decision was rendered by the Board, 

An Appeal was filed for the *632 Application with an Appeal Brief being filed August 
20, 2007. An Examiner's Answer was mailed December 13, 2007. As of this time, no 
decision has been rendered by the Board for the appeal of the '632 Application. 
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There are no other further appeals, interferences, or judicial proceedings which will 
directly affect or be directly affected by or have a bearing on the Board's decision in this 
appeal known to Applicant's attorney. 

IIL STATUS OF CLAIMS 

A. Total Number of Claims in Application 
There are 37 claims pending in application. 

B. Current Status of Claims 

K Claims canceled: None 

2. Claims withdrawn from consideration but not canceled: None 

3. Claims pending: 1-37 

4. Claims allowed: None 

5. Claims rejected: 1-37 

C. Claims On Appeal 

The claims on appeal are claims 1-37 

IV. STATUS OF AMENDMENTS 

A firsi Office Action was mailed for this application September 22, 2004. In 
response, Applicant filed an Amendment on December 22, 2004, which presented an 
amendment to claim 5, A Fhial Office Action was then mailed April 20, 2005. Applicant did 
not file an amendment in response to the Final Office Action, but instead filed a Notice of 
Appeal on July 19, 2005 arid filed a supporting Appeal Brief on September 19, 2005. The 
rejection at issue in that appeal was tlialall of claims 1-37 siood rejected under 35 U.S.C. 
§ 102(e) as being anticipated by U.S. Patent No. 6,775,692 issued to Albert et al CAlherr). 

In response to such Appeal Brief, the Examiner did not submit an Answer, but instead 
reopened prosecution and mailed an Office Action dated ApriL6,.2006„whichTaised.a 
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Restriction Requirement. Applicant traversed the Restriction Requirennent in a response date 
May 5, 2006, and the Restriction Requirement was withdrav/n in an Ofiice Action mailed 
July 27, 2006. However, the July 27, 2006 Office Action rejected the claims on new 
grounds, namely rejecting all of claims 1-37 under 35 U.S .C. §103(a) as being unpatentable 
over Albert in view of U.S. Patent No. 5,774,660 issued to Brendel et ai {''Brendery 
Applicant submitted a response on October 25, 2006 which did not amend any claims, but 
instead pointed out that Brendel does not correct the deficiencies of Albert that were notied in 
the previous Appeal. 

A Final Office Action was then mailed January 12, 2007 that maintained the rejection 
of claims 1-37 under 35 U.S.C. § 103(a) as being unpatentable over Albert in view of 
Brendel, Applicant did not file an amendment in response to the Final Office Action, but 
instead filed a Notice of Appeal on April 5, 2007 and filed a supporting Appeal Brief on June 
5, 2007, ITie rejection at issue in that $pp^al was that all of claims 1 -37 stood rejected under 
35 U.S.C. §103(a) as being unpatentable ovox Albert in view of Brendel), 

In response to such Appeal Brief, the Examiner did not submit an Answer, but instead 
reopened prosecution and mailed an Office Action dated April 30, 2008 which raised a new 
rejection of claims 1-37 under 35 U.S.C, §1 03(a) as being unpatentable over Albert in view of 
U.S. Patent no. 6,760,775 issued to Anerousis etal CAnerousis'') . 

Applicant did not file an amendment in response to the Office Action of April 30, 
2008, but instead filed a Notice of Appeal on September 2, 2008 which this brief supports. 

Thus, the claims on appeal ains those claims rejected in the Office Action of April 30, 
2008, and a listing of those claims arp provided in Appendix A hereto. 

V. SUMMARY OF CLAIMED SUBJECT MArfER 

The following provides a concise explanation of the subject matter defined in the 
claims involved in the appeal, referring to the specification by page and line number and to 
the drawings by reference characters, as required by 37 C.F.R. § 41 .37(c)(l)(v). Each 
element of the claims is identified by a corresponding reference to the specification and 
dra>vings where app,H^^^^ Note that tfe to, passages in J^^^^ 
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drawings for each claim element does not imply that the limitations from the specification 
and drawings should be rsad into tlie corresponding claim element. 

According to one claimed embodiment of the present invention, a method of TCP 
stale migration in a communication network comprises establishing a TCP/IP communication 
session between a client computer (e.g., client 410 of Figure 4) and a first server computer 
(e.g., server 450 of Figure 4). Tlie first server computer is part of a plurality of server 
computers forming a web cluster containing information (e.g., web cluster 490 of Figure 4). 
The communication session is established for the transfer of data contained within the 
information. The method further comprises handing off the communication session to a 
selected server computer (e.g., server 452 of Figure 4, and see page 23, lines 9- 1 3 of the 
specification) from the first server computer over a persistent control channel using TCP 
handoff modules (e.g., Upper TCP module 522 and Bottom TCP module 524 of Figure 5C, 
and see page line 25 - page 1 1 , line 6, and page 29, line 27 ~ page 30, line 6 of the 
specification) that are dynamically loadable {see page 17, line 24 - page 18, line 15 of the 
specification) within TCP/IP stacks in operating systems located at both the first server 
computer and the selected server computer, that implement a TCP handoff protocol that 
works within kernel levels of an existing TCP/IP protocol (see page 23, line 21 — page 26, 
line 29 of the specification). The method fiirther comprises migrating a first TCP state of the 
first server computer to the selected server computer, and a second TCP state of the selected 
server computer to the first server computer over the control channel (e.g., page 10, line 26 - 
page 1 1 , line 28 of the specification). 

In one embodiment, establishing the TCP/IP communication session fiirther 
comprises receiving a SYN packet from the client at a first BTCP module located at the first 
server computer (block 1010 of Figure 10); sending the SYN packet upstream to a first TCP 
module located above the first BTCP module in a first operating system of the first server 
computer (block 1020 of Figure 10); receiving a first SYN/ACK packet from the first TCP 
module (block 1030 of Figure 10); parsing the first initial TCP state fi*om the first SYN/ACK 
packet, including a first initial sequence number for the first TCP module associated with the 
TCP/IP communication session (block 1040 of Figure 10); sending the SYN/ACK packet to 
the client (block 1050 of Figure 10); receiving an ACK packet from the client at the first 
BTCP module (block 1060 of Figure 10); sending the ACKpacket to the first TCP module 
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(block 1070 of Figure 10); receiving a web request packet associated with the TCP/IP 
communication session at the first BTCP module at the first server computer (block 1080 of 
Figure 10); and storing the SYN, ACK and the web request packet at the first server 
computer (block 1090 of Figure 10). 

In one embodiment, handing off the communication session further comprises 
examining content of the web request packet; determining which of the plurality of server 
computers, a selected server computer, can best process the WEB request packet, based on 
the content (page 10, lines 7-16 of the specification); sending a handoff request from said first 
BTCP module to a second BTCP module at the selected server computer over the control 
channel, if the selected server computer is not the first server computer; including the SYN 
packet and the ACK packet in the handoff request packet; changing a first destination IP 
address of said SYN packet to a second IP address of said selected server computer, at said 
second BTCP module; sending said SYN packet to said second TCP module; receiving a 
second SYN/ACK packet at said second BTCP module; parsing said second initial TCP state 
from said second SYN/ACK packet, including a second initial sequence number, for said 
second TCP module, that is associated with said TCP/IP communication session; changing a 
second destination IP address of said ACK packet to said second IP address, at said second 
BTCP module; updating said ACK packet to reflect said second TCP state of said selected 
server computer in said communication session; sending said ACK packet that is updated to 
said second TCP module; and sending a handoff acknowledgment message to said first BTCP 
module. 

According to another claimed embodiment, a method of TCP slate migration in a 
communication network comprises establishing a TCP/IP communication session between a 
client computer (e.g., client 410 of Figure 4) and a first server computer (e.g., server 450 of 
Figure 4). The first server computer is part of a plurality of server computers forming a web 
cluster containing information (e.g., web cluster 490 of Figure 4), and the communication 
session is established for the transfer of data contained within the information. The method 
further comprises monitoring traffic associated with establishing said TCP/IP communication 
session to understand a first initial TCP state of the first server computer associated with the 
TCP/IP comraunication session, at a first bottom-TCP (BTCP) module at the first server 
computer (Bottom TCP module 524 of Figure' 5 and BTCP module 830 of Figure 8, and see 
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page 9, lines 16-20 and page 11, lines 8-1 1 of the specification). The method further 
comprises receiving a web request associated with the TCP/IP communication session at the 
first BTCP module at the first server computer (block 910 of Figure 9 and block 1 3 1 0 of 
Figure 13, and see page 10, lines 7-8 of the specification). The method further comprises 
examining content of the web request, and determining which of the plurality of server 
computers C*a selected serv^er computer") can best process the web request, based on the 
content (block 930 of Figure 9, and see page 10, lines 13-16 of the specification). The 
method further comprises handing off the communication session to the selected server (e.g., 
server 452 of Figure 4) computer from the first server computer over a persistent control 
channel, if the selected server computer is not the first server computer {see page 10, line 26 
- page 11, line 28 and page 23, lines 9-13 of the specification). The method further 
comprises monitoring traffic associated with handing off the TCP/IP communication session 
to understand a second initial TCP state of the selected server computer associated with the 
TCP/IP cortinumication session, at a second BTCP module at the selected server computer 
(e.g., BTCP module 870 of Figure 8, and see page 12, lines 1-13 of the specification). The 
method further comprises migrating the first initial TCP state to the selected server computer 
over the control channel, such that the second BTCP module can calculate a first TCP state 
for the first server computer in the TCP/IP communication session (e.g., page 12, line 15 - 
page 13» line 8 of the specification). The method fiirther comprises sending a second initial 
TCP state of the selected server computer to the first BTCP module (e.g., BTCP module 830 
of Figure 8), such that the first BTCP module can calculate a second TCP state for the 
selected server computer in the TCP/IP communication session. The method further 
comprises forwarding daca packets received at the first BTCP module from the client to the 
selected ser\'er computer, by changing the data packets to reflect the second TCP slate and a 
second IP address of the selected server computer (e.g., block 1 320 of Figure 13, and see 
page 1 2, line 1 5 - page 1 3, line 8 of the specification). The method further comprises 
sending response packets from the selected server computer directly to the client computer 
(see Figures 3 and 4) by changing the response packets to reflect the first TCP state and a first 
tP address of the first server computer (e.g., block 1 440 of Figure 14, and see page 1 2, line 
15- page 13, line 8 of the specification). And, the method farther comprises terminating the 
TCP/IP communication session at the first server computer when the TCP/IP communication 
sessjon is closed (e.g», page 13, lines 10-19)* 
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According to another claimed embodiment, a server computer comprises an upper 
TCP (UTCP) module (e.g,, UTCP module 522 of Figure 5C, and UTCP modules 810 and 850 
of Figure 8) located above a TCP module (e.g., TCP module 520 of Figures 5B and 5C, and 
TCP modules 820 and 860 in Figure 8) in an operating system of the server computer. The 
server computer further comprises a bottom TCP (BTCP) module (e.g., BTCP module 524 of 
Figure 5C» and BTCP modules 830 and 870 of Figure 8) located below the TCP module. The 
UTCP, TCP, and BTCP modules implement a method of handing off a communication 
session between a first node (e.g., server 450 of Figure 4, and "front-end" node of Figure 8) 
and second node (e.g., server 452 of Figure 4, and "back-end" node of Figure 8) in a cluster 
network (e.g.. cluster 490 of Figure 4) that works within the kernel level of an existing 
TCP/IP protocol, by migrating TCP states associated with the first and second nodes {see 
page 10, line 26 - page 12, line 13 of the specification). 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Claims 1-37 are rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. 
Patent No. 6,775,692 issued to Albert et al (hereinafter Albert") in view of U.S. Patent No. 
5,774,660 issued to Anerousis et al i^^Aueromis'^), 

VII. ARGUMENT 

Appellant respectfully traverses the outstanding rejections of the pending claims, and 
requests that the Board reverse the outstanding rejections in light of the remarks contained 
herein. Below, Appellant argues many of the rejected claims separately. Thus, Appellant 
respectfully asserts that separately argued claims do not stand or fall together, see 37 C.F.R. § 
41.37(c)(])(vii). 

The test for determining if a claim is rendered obvious by one or more references for 
purposes of a rejection under 35 U.S.C, § 103 is set forth in KSR International Co. v. Teleflex 
Inc., 550 U.S._, 82 USPQ2d 1385 (2007): 

'*Under §103, the scope and content of the prior art are to be determined; differences 
bctvi^een the prior art and the claims at issue are to be ascertained; and the level of ordinary 
skill in the pertinent art resolved. Against this background the obviousness or 
nonobviousncss of the subject matter is determined. Such secondary considerations as 
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commercial success, long felt but unsolved needs, failure of others, etc., might be utilized to 
give light to the circumstances surrounding the origin of the subject matter sought to be 
patented," Quoting Graham v. John Deere Co. of Kansas City, 383 U.S. 1 (1966). 

Accoiding to the Examination Guidelines for Determining Obviousness Under 35 
U.S.C. 103 in view of KSR Inteniational Co. v. Teleflex Inc., Federal Register, Vol. 72, No. 
195, 57526, 57529 (October 10, 2007), once the Graham factual inquiries are resolved, there 
must be a determination of whether the claimed invention would have been obvious to one of 
ordinary skill in the art based on any one of the following proper rationales: 

(A) Combining prior art elements according to known methods to yield predictable 
results; (B) Simple substitution of one known element for another to obtain predictable 
results; (C) Use of known technique to improve similar devices (methods, or products) in the 
same way; (D) Applying a known technique to a known device (method, or product) ready 
for improvement to yield predictable results; (E) ''Obvious to try*' — choosing from a finite 
number of identified, predictable solutions, with a reasonable expectation of success; (F) 
Known work in one field of endea vor may prompt variations of it for use in either the same 
field or a different one based on design incentives or other market forces if the variations 
would have been predictable to one of ordinary skill in the art; (G) Some teaching, 
suggestion, or motivation in the prior art that would have led one of ordinary skill to modify 
the prior art reference or to combine prior art reference teachings to arrive at the claimed 
invention. KSR International Co. v. Teleflex Inc., 550 U.S._, 82 USPQ2d 1385 (2007). 



Furthermore, as set forth in KSR International Co. v. Teleflex Inc., quoting from In re 
Kahn, 441 F. 3d 977, 988 (CA Fed. 2006), "[R]ejections on obviousness grounds cannot be 
sustained by mere conclusory statements; instead, there must be some articulated reasonings 
with some rational underpinning to support the legal conclusion of obviousness." 

Furthermore, as set forth in MPEP 2143.03, to ascertain the differences between the 
prior art and the claims at issue, '*[a]l] claim limitations must be considered" because "all 
words in a claim must be considered in judging the patentability of that claim against the 
prior art;" In re Wilsoii, 424 F:2aT582, 1385. 
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If the above-identified criteria and rationales are not met, then the cited 
references fail to render obvious the claimed invention and, thus, the claimed invention is 
distinguishable over the cited references. 

The test for non-obvious subject matter is whether the differences behveen the subject 
matter and the prior art are such that the claimed subject matter as a whole would have been 
obvious to a person having ordinary skill in the art to which the subject matter pertains. The 
United States Supreme Court in Graham v, jQhn Deere and Co. . 383 U.S. 1 (1966) set forth 
the factual inquiries which must be considered in applying the statutory test: (1) determining 
of the scope and content of the prior art; (2) ascertaining the differences between the prior art 
and the claims at issue; and (3) resolving the level of ordinary skill in the pertinent art. As 
discussed further hereafter, Applicant respectfully asserts tliat the claims include non-obvious 
differences over the cited art. 

As discussed further below, when considering the scope and content of the applied 
Albert md Aneroitsis references there are significant differences between the applied 
combination and the claims, as the applied combination fails to disclose all elements of the 
claims. Hius, considering the lack of disclosure in the applied combination of all elements of 
the claims, one of ordinary skill in the art would not find the claims obvious under 35 U.S.C. 
§103, and therefore the rejections should be overturned. 

Indeucndent Claim 1 

Independent claim 1 recites: 

In a communication network, a method of TCP state migration 
comprising the steps of: 

a) establishing a TCP/IP communication session between a client 
computer and a first server computer, said first server computer part of a 
plurality ofserver computers forming a web cluster containing information, 
said communication session established for the transfer of data contained 
within said information; 

b) handing off said communication session to a selected server 
computer from said first server computer over a persistent control channel 
using TCP handoff modules that are dynamically loadable v^ithin TCP/IP 
stacks in operating systems located at both said first server computer and said 
selected server computer, that implement a TCP handoff protocol that works 

" vvithiiT kernel Icvcls^^^^ 
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c) migrating a first TCP state of said first server computer to said 
selected server coriiputer^ and a second TCP state of said selected server 
computer to said first server computer over said control channel. (Emphasis 
added). 

The combination of Albert eindAnerousis fails to teach or suggest all elements of 
independent claim 1 . For the reasons discussed at length in the Appeal Brief of January 5, 
2006, Albert fails to disclose at least: 

A) TCP handoff modules that are dynamically loadable within TCP/IP stacks in 
operating systems located at both said first server computer and said selected server 
computer; 

B) handing off said communication session; and 

C) a persistent control channel. 

The Office Action of April 30 concedes that Alberi fails to teach or suggest "b) 
handing off said communication session to a selected server computer from said first server 
computer over a persistent control channel using TCP handoff modules that are dynamically 
loadable within TCP/IP stacks in operating systems located at both said first server computer 
and said selected server computer, that implement a TCP handoff protocol that works within 
kernel levels of an existing TCP/IP protocol", see page 3 of the Office Action of April 30, 
2008. However, the Office Action of April 30 asserts ihzt Aneroiisis discloses this element of 
the claim. Appellant respectfully disagrees, as discussed below. 

Anerousis fails to provide TCP handoff modules within TCP/IP stacks in operating 
systems that implement a TCP handoff protocol that works within kernel levels of an existing 
TCP/IP protocol. The Office Action of April 30, 2008 states on Page 4 "'Anerousis teaches a 
system-specific SLR [service level router] cluster directing requests to site-specific SLR 
clusters direcring network service requests to a particular hosting server within a site hosting 
the network service (at least col 7:49-67; 8:7-45)/' 

In the first exemplary embodiment of the invention, service level 
routing is perfonned by a site-specific SLR cluster in a single set of process 
steps. Specifically, nenvork service requests are directed to a site-specific SLR 
cluster that directs the service requests to a particular host server within the 
physical host site. As shown in FIG. 2, an AS 200 includes a physical host site 
210 with its own site-specific SLR cluster 220. The site-specific SLR cluster 
220 receives network service requests from client or client* custorher 
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tenninals, e.g., terminal 230, coupled to the SLR cluster 220 through some 
type of network 240, which may be the Internet, The site-specific SLR cluster 
220 is located at the entry gateway to the physical host site 210. The site- 
specific SLR cluster 220 directs the network service request to a particular 
hosting server 250 within the physical host site 210 hosting the network 
service. The hosting server 250 than responds to the service request by, for 
example, providing the requested service to the client or client' customer at 
terminal 220. Col. 7, lines 49-60; 

However, the hosting server 250 is not bound to respond to the service 
request on the same transmission path traveled by the service request. 
Therefore, the response may be transmitted on a different path through various 
routers 260 in the TD 200 for any number of reasons including, path load, 
transmission cost reliability, available bandwidth, etc. Col. 8, lines 1-6. 



These cited sections are a high level discussion of routing of service requests to 
physical host sites that may support a number of virtual hosts. There is no discussion of the 
elements of the claim such as handoff modules, TCP/IP stacks in operating systems or a TCP 
handoff protocol that works within the kernel levels of an existing TCP/IP protocol." 

Thus, for at least the above reasons, the combination of Albert and Anerousis fails to 
disclose all elements of claim 1. As such, the rejection of claim 1 should be ovemimed, and 
claim 1 should be passed to allowance. 
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Independent Claim 11 

Independent claim 1 1 recites: 

In a communication network, a method of TCP state migration 
comprising the steps of: 

a) establishing a TCP/IP communication session between a client 
computer and a first server computer, said first server computer part of a 
plurality of server computers forming a web cluster containing information, 
said communication session established for the transfer of data contained 
within said information; 

b) monitoring traffic associated with establishing said TCP/IP 
communication session to understand a first initial TCP state of said first 
server computer associated with said TCP/IP communication session, at a first 
bottom-TCP (BTCP) module at said first server computet^ 

c) receiving a web request associated with said TCP/IP 
communication session at said first BTCP module at said first server 
computer; 

d) examining content of said web request; 

e) determining which of said plurality of server computers, a 
selected server computer, can best process said web request, based on said 
content; 

f) handing off said communication session to said selected server 
computer from said first server computer over a persistent contn^l channel, if 
said selected server computer is not said first server computer; 

g) monitoring traffic associated with handing off said TCP/IP 
communication session to understand a second initial TCP slate of said 
selected server computer associated with said TCP/IP communication session, 
at a second BTCP module at said selected server computer; 

h) migrating said first initial TCP state to said selected server 
computer over said control channel, such that said second BTCP module can 
calculate a first TCP state for said first server computer in said TCP/IP 
communication session; 

i) sending a second initial TCP state of said selected server 
computer to said first BTCP module, such that said first BTCP module can 
calculate a second TCP state for said selected server computer in said TCP/IP 
communication session; 

j) forwarding data packets received at said first BTCP module 
from said client to said selected server computer, by changing said data 
packets to reflect said second TCP state and a second IP address of said 
selected server computer; 

k) sending response packets firom said selected server computer 
directly to said client computer by changing said response packets to reflect 
said first TCP state and a first IP address of said first server computer; and 

1) terminating said TCP/IP communication session at said first 
server computer when said TCP/IP communication session is closed. 
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Tlie combination of Aiheii and Auerousis fails to teach or suggest all elements of 
independent claim IL As discussed further in the Appeal Brief of January 5, 2006, Albert 
fails to disclose at least: 

A) a first bottom-TCP (BTCP) module at said first server computer, and a second 
BTCP module at said selected server computer, 

B) examining content of said web request and detemining which of said plurality of 
server computers, a selected server computer, can best process said web request, based on 
said content; 

C) sending response packets from said selected server computer directly to said client 
computer; 

D) handing off said communication session; and 

E) a persistent control channel. 

Further, Anerousis fails to teach or suggest at least a first bottom-TCP (BTCP) 
module at said first server computer, and a second BTCP module at said selected server 
computer, as recited by claim 1 1 . Thus, for at least the above reasons, the combination of 
Aiberi and Anerousis fails to disclose all elements of claim 11. As such, the rejection of 
claim 1 1 should be overtumed, and claim 1 1 should be passed to allowance. 
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Independent Claim 26 

Independent claim 26 recites: 

A server computer comprising: 

an upper TCP (UTCP) module located above a TCP module in an 
operating system of said server computer; 

a bottom TCP (BTCP) module located below said TCP module, said 
UTCP, TCP, and BTCP modules implementing a method of handing off a 
communication session between a first node and second node in a cluster 
network that works within the kernel level of an existing TCP/IP protocol, by 
migrating TCP states associated with said first and second nodes. 

The combination of Albert and Anerousis fails to teach or suggest all elements of 
independent claim 26. As discussed further in the Appeal Brief of January 5, 2006, Albert 
fails to disclose tlie recited UTCP and BTCP modules. 

Further, Anerousis fails to disclose the UTCP and BTCP modules. For example, 
Anerousis does not disclose UTCP. TCP, and BTCP modules that implement a method of 
handing off a communication session between a first node and second node in a cluster 
network that works within the kernel level of an existing TCP/IP protocol as recited by claim 
26. Thus, for at least the above reasons, the combination of Albert euMi Anerousis fails to 
disclose all elements of claim 26. As such, the rejection of claim 26 should be overturned, 
and claim 26 should be passed to allowance. 
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Dependent Claim 2 

Claim 2 depends from claim 1 and thus inherits all elements of claim 1 . Accordingly, 
claim 2 is allowable over the combination of Albert in view ofAnerousis at least for the 
reasons discussed above with claim 1 . Additionally, claim 2 fiirther recites: 

The method as described in Claim U wherein said step a) comprises 
the steps of: 

receiving a SYN packet from said client at a first BTCP module 
located at said first server computer; 

sending said SYN packet upstream to a first TCP module located 
above said first BTCP module in a first operating system of said first ser\'er 
computer; 

receiving a first SYN/ACK packet from said first TCP module; 

parsing said first initial TCP state from said first SYN/ACK packet, 
including a first initial sequence number for said first TCP module associated 
with said TCP/IP communication session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said first BTCP module; 

sending said ACK packet to said first TCP module; 

receiving a web request packet associated with said TCP/IP 
communication session at said first BTCP module at said first server 
computer; 

storing said SYN, ACK and said web request packet at said first server 
computer. 

The combination of Albert in view of Anerousis fails to disclose all of the further 
elements of claim 2, The Final Office Action appears to rely upon Albert as disclosing all 
elements of claim 2 {see pages 4-5 of the Final Office Action), as the reasoning for rejecting 
claim 2 appears to be the same as in the Final Office Action of April 20, 2005 (in which 
claim 2 was rejected as being anticipated by Albert). However, Albert fails to disclose all 
elements of claim 2. For instance, Albert fails to disclose at least the recited first BTCP 
module located at said first server computer. V\xti\i^t, Anerovsis does not appear to be relied 
upon in the reje;ction of claim 2 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that tlie rt;jection of claim 2 be 
overlumed. 
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Dependent Claim 3 

Claim 3 depends from claim 2, which depends from claim 1, and thus claim 3 inherits 
all elements of claims 1 and 2. Accordingly, claim 3 is allowable ovqv Albert in view of 
Aiwrousis at least for the reasons discussed above with claims 1 and 2. Additionally, claim 3 
further recites: 

Tlie method as described in Claim 2, wherein said step b) comprises 

the steps of: 

examining content of said web request packet : 

determining which of said plurality of server computers, a selected 

server computer, can best process said WEB request packet, based on said 

content : 

sending a handoff request from said first BTCP module to a second 
BTCP module at said selected ser\^er computer over said control channel, if 
said selected server computer is not said first server computer; 

including said SYN packet and said ACK packet in said handoff 
request packet; 

changing a first destination IP address of said SYN packet to a second 
IP address of said selected server computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second SYN/ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ACK 
packet, including a second initial sequence number, for said second TCP 
module, that is associated with said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said 
second IP address, at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said 
selected server computer in said communication session; 

sending said ACK packet that is updated to said second TCP module; 

and 

sending a handoff acknowledgment message to said first BTCP 
module. 

The combination of Albert in view of Aneromis fails to disclose all of the further 
elements of claim 3. The Office Action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 3 {see pages 5-6 of the Final Office Action), as the reasoning 
for rejecting claim 3 appears to be the same as in the Final Office Action of April 20, 2005 
(in which claim 3 was rejected as being anticipated by Albert). However, Albert fails to 
disclose all elements of claim 3. For instance, Albert fails to teach at least the recited second 
BTCP module at said selected server computer. Further, as discussed below with 
independent claim 11, vl/6er^ fails to teaich examining content of said web request Wackef ^a^^^ 
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determining which of said plurality of server computers, a selected server computer, can best 
process said WEB request packet, based on said content . Further, Anerousis does not appear 
to be relied upon in the rejection of claim 3 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 3 be 
overturned. 

Dependent Claim 4 

Claim 4 depends from claim 3, which depends from claim 2 v^hich depends from 1 , 
and thus claim 4 inherits all elements of claims 1 , 2, and 3. Accordingly, claim 4 is allowable 
over Albert in view of Anerousis at bast for the reasons discussed above with claims 1 -3. 
Additionally, claim 4 further recites: 

The method as described in Claim 3, wherein step c) comprises the 
steps of: 

monitoring traffic associated with establishing said TCP/IP 
communication session in step a), at said first BTCP module, to parse a first 
initial TCP state of said first server computer, said first itiitial TCP state 
associated with said TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over 
said control channel by including said first initial TCP state in said handoff 
request packet, said first initial TCP state including a first sequence number, 
such that said second BTCP module can calculate said first TCP state for said 
first server computer in said TCP/IP communication session. 

The combination of Albert in view of Anerousis fails to disclose all of the further 
elements of claim 4. The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 4 {see page 7 of the Office action of April 30, 2008), as the 
reasoning for rejecting claim 4 appears to be the same as in the Final Office Action of April 
20, 2005 (in which claim 4 was rejected as being anticipated by Albert). However, Albert 
fails to disclose all elements of claim 4. For instance, Albert fails to teach at least the recited 
''migrating said first initial TCP state to said second BTCP module over said control channel 
by including said first initial TCP state in said handoff request packet, said first initial TCP 
state including a first sequence number". Further, Anerousis does not appear to be relied 
upon in the rejection of claim 4 as disclosing these elements, nor does it do so. 
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Accordingly, Appellant respectfully requests that the rejection of claim 4 be 
overturned. 

Dependent Claim S 

Claim 5 depends from claim 3, which depends from claim 2 which depends from 1, 
and thus claim 5 inherits all elements of claims 1 , 2, and 3. Accordingly, claim 5 is allowable 
owQtAlbefi in view of Aiierotisis at least for the reasons discussed above with claims 1-3. 
Additionally, claim 5 further recites: 

The method as described in Claim 3, wherein step c) comprises the 
steps of: 

monitoring traffic associated with handing off said TCP/TP 
communication session at said second BTCP module, to parse a second initial 
TCP state of said selected server computer, said second initial TCP state 
associated with said TCP/IP communication session; and 

migrating said second initial TCP state of said selected server 
computer to said first BTCP module by including said second initial TCP state 
in said handoff acknowledgment packet, said second initial TCP state 
including a second initial sequence number, such that said first BTCP module 
can calculate said second TCP state for said selected server computer in said 
TCP/IP communication session. 

The combination of Albert in view of Auerousis fails to disclose all of Ihe further 
elements of claim 5. 'Die Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 5 {see page 7 of the Office action of April 30, 2008), as the 
reasoning for rejecting claim 5 appears to be the same as in the Final Office Action of April 
20, 2005 {in which claim 5 was rejected as being anticipated by Albert). However, Albert 
fails to disclose all elements of claim 5, For instance, Albert fails to teach at least the recited 
'^migrating said second initial TCP state of said selected server computer to said first BTCP 
module by including said second initial TCP state in said handoff acknowledgment packet, 
said second initial TCP state including a second initial sequence number'*. Further, Aneromis 
does not appear to be relied upon in the rejection of claim 5 as disclosing these elements, nor 
does it do so. 

Accordingly, Appellant respectfiilly requests that the rejection of claim 5 be 
overturned. 
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Dependent Claim 6 

Claim 6 dqjends from claim 2, which depends from claim 1 , and thus claim 6 inherits 
all elements of claims 1 and 2, Accordingly, claim 6 is allowable over Albert in view of 
Anerousis at least for the reasons discussed above with claims 1 and 2. Additionally, claim 6 
further recites: 

The method as described in Claim 2, comprising the further steps of: 
intercepting a connection indication message sent from said first TCP 
module to an application layer above said first TCP module at a first upper- 
TCP (UTCP) module, said connection indication message sent by said first 
TCP module upon establishing said communication session; and 

holding said connection indication message at said first UTCP module. 

The combination of Albert in view of Anerousis fails to disclose all of the flirther 
elements of claim 6. The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 6 {seepage 8 of die Office action of April 30, 2008), as the 
reasoning for rejecting claim 6 appears to be the same as in the Final Office Action of April 
20, 2005 (in which claim 6 was rejected as being anticipated by Albert), However, Albert 
fails to disclose all elements of claim 6, For instance, Albert foils to teach at least the recited 
first upper TCP UTCP) module. Further, Anerousis does not appear to be relied upon in the 
rejection of claim 6 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 6 be 
overtumed. 
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Dependent Claim 7 

Claim 7 depends from claim 6, which depends from claim 2 which depends from 
claim 1 » and tlius claim 7 inherits all elements of claims 1 , 2, and 6. Accordingly, claim 7 is 
allowable over Albert in view ofAnerousis at least for the reasons discussed above with 
claims 1, 2, and 6. Additionally, claim 7 further recites: 

The method as described in Claim 6, wherein said method comprises 
the further steps of: 

sending a reset packet from said first BTCP module upon receiving 
said handoff acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP 
module; 

receiving incoming data packets from said client at said first BTCP 

module; 

changing said destination addresses of said incoming data packets to 
said second IP address; 

updating sequence numbers and TCP checksum in said data packets to 
reflect said second TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

Tlie combination of ^/ter/ in view of Anerousis fails to disclose all of tlie further 
elements of claim 7. The Office action of April 30, 2008 appears to rely Albert as 
disclosing all elements of claim 7 {see pages 8-9 of the Office action of April 30, 2008), as 
the reasoning for rejecting claim 7 appears to be the same as in the Final Office Action of 
April 20, 2005 (in which claim 7 was rejected as being anticipated by Albert), However, 
Albert fails to disclose all elements of claim 7. For instance, Albert fails to teach at least the 
recited "sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module". Further, Anerousis does not appear to be 
relied upon in the rejection of claim 7 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 7 be 
overturned. 
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Dependent Claim 8 

Claiin 8 depends from claim 6, which depends from claim 2 which depends from 
claim 1, and thus claim 8 inherits all elements of claims 1, 2, and 6. Accordingly, claim 8 is 
allowable oyer Albert in view ofAnerousis at least for the reasons discussed above with 
claims 1, 2, and 6. Additionally, claim 8 fiirther recites: 

The method as described in Claim 6, comprising the further steps of: 
sending notification from said first BTCP module to said first UTCP 

module to release said connection indication message, if said selected server 

computer is said first server computer; 

sending incoming data packets, including said web request packet, 

from said client, received at said first BTCP module, upstream. 

The combination o{ Albert in view ofAnerousis fails to disclose all of the further 
elements of claim 8. The OfTice action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 8 (see page 9 of the Office action of April 30, 2008), as the 
reasoning for rejecting claim 8 appears to be the same as in the Final Office Action of April 
20, 2005 (in which claim 8 was rejected as being anticipated by Albert), However, Albert 
fails to disclose all elements of claim 8. For instance, Albert fails to teach at least the recited 
"sending notification from said first BTCP module to said first UTCP module to release said 
connection indication message, if said selected server computer is said first server computer". 
Further, Anerousis does not appear to be relied upon in the rejection of claim 8 as disclosing 
these elements, nor does it do so* 

Accordingly, Appellant respectfully requests that tlic rejection of claim 8 be 
overturned. 
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Dependent Glaim 9 

Claim 9 depends from claim 1 and thus inherits all elements of claim 1. Accordingly, 
claim 9 is allowable ovtx Albert in view of Anerousis at least for the reasons discussed above 
with claim 1. Additionally, claim 9 further recites: 

The method as described in Claim 1, comprising the further step of: 
intercepting outgoing response packets from said selected server 

computer at a second bottom TCP (BTCP) module located at said selected 

server computer; 

changing source addresses of said response packets to a first IP address 
of said first server computer, 

updating sequence numbers and TCP checksum in said response 
packets to reflect said first TCP state of said first server computer; and 

sending said response packets to said client. 

The combination of Albert in view of Anerousis fails to disclose all of the further 
elements of claim 9. The Office action of April 30, 2008 appears to rely upon Albert SiS 
disclosing all elements of claim 9 {see pages 9-10 of the Office action of April 30, 2008), as 
the reasoning for rejecting claim 9 appears to be the same as in the Final Office Action of 
April 20, 2005 (in which claim 9 was rejected as being anticipated by Albert), However, 
Albert fails to disclose all elements of claim 9. For instance, Albert fails to teach at least the 
recited second bottom TCP (BTCP) module located at said selected server computer 
Further, Anerousis does not appear to be relied upon in the rejection of claim 9 as disclosing 
these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 9 be 
overturned. 



J00!0Sl2-).S.doc 



23 



Application No.: 09/880,631 



Docket No.: 10010812-1 



Dependent Claim 10 

Claim 1 0 depends from claim 1 and thus inherits all elements of claim 1 . 
Accordingly, claim 10 is allowable over Albert in view oiAnerousis at least for the reasons 
discussed above with claim 1. Additionally, claim 10 further recites: 

The method as described in Claim 1, comprising the further steps of: 

monitoring TCP/IP control traffic for said communication session at 
said second BTCP module; 

understanding when said communication session is closed at said 
second server computer; 

sending a termination message to said first server computer over said 
control channel; 

terminating said TCP/IP communication session at said first server 
computer by terminating a forwarding mode at said first BTCP module; and 

freeing data resources associated with said communication session at 
said first server computer. 

The combination of Albert in view oiAnerousis fails to disclose all of the further 
elements of claim 10. Tlie Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 10 {see page 10 Of the Office action of April 30, 2008), as the 
reasoning for rejecting claim 10 appears to be the same as in the Final Office Action of April 
20, 2005 (in which claim 10 was rejected as being anticipated by Albert). Eoy^eveVy Albert 
fails to disclose all elements of claim 10. For instance, Albert fails to teach at least the recited 
first and second bottom TCP (BTCP) modules. Further, Anerousis does not appear to be 
relied upon in the rejection of claim 10 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respcctftilly requests that the rejection of claim 10 be 
overturned. 
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Dependent Claim 12 

Claim 12 depends from claim 1 1 and thus inherits all elements of claim 11. 
Accordingly, claim 12 is allowable over Alberi in view ofAnerousis at least for the reasons 
discussed above with claim 1 1. Additionally, claim 12 further recites: 

The method as described in Claim 1 1, wherein said step a) comprises 
the steps of: 

receiving a packet from said client at said fint BTCP module; 

sending said SYN packet upstream to a first TCP module located 
above said first BTCP module in a first operating system of said first server 
computer; 

receiving a first SYK/ACK packet from said first TCP module; 

parsing said first initial TCP state fi-om said first SYN/ ACK packet, 
inckiding a first initial sequence number for said first TCP module associated 
with, said TCP/IP communication session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said first BTCP module; 

sending said ACK packet to said first TCP module; 

storing said SYN, ACK and said web request at said first server 
computer. 

The combination of Albert in view of Anerousis fails to disclose all of the further 
elements of claim 1 2. The Office action of April 30, 2008 appears to rely upon Albeit as 
disclosing all elements of claim 12, as the reasoning for rejecting claim 1 2 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 12 was rejected as being 
anticipated by Albert). However, Albert fails to disclose all elements of claim 12. For 
instance, Albert fails to teach at least the recited ''sending said SYN packet upstream to a first 
TCP module located above said first BTCP module in a first operating system of said first 
server computer". Further, Anerousis does not appear to be relied upon in the rejection of 
claim 12 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 12 be 
overturned. 
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Dependent Claim 13 

Claim 13 depends from claim 1 1 and thus inherits all elements of claim 11. 
Accordingly, claim 13 is allowable over Aiberi in view ofAnerousis at least for the reasons 
discussed above with claim 1 1 . Additionally, claim 13 ifurther recites: 

The method as described in Claim 1 1 , wherein said step e) comprises 
the steps of: 

sending a handoff request packet from said first BTGP module to said 
second BTCP module over said control channel; 

including said S YN packet and said ACK packet in said handoff 
request packet; 

changing a first destination IP address of said SYN packet to a second 
IP address of said selected server computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second S^^N/ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ ACK 
packet, including a second initial sequence number, for said second TCP 
module, tbat is associated with said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said 
second IP address, at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said 
selected server computer in said communication session; 

sending said ACK packet that is updated to said second TCP module; 

and 

sending a handoff acknowledgment message to said first BTCP 
module. 

The combination of Aiberi in view o^Anerousis fails to disclose all of the further 
elements of claim J 3. The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 13, as the reasoning for rejecting claim 13 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 1 3 was rejected as being 
anticipated by Albert), However, Albert fails to disclose all elements of claim 13. For 
instance, Albert fails to teach at least the recited ''changing a second destination IP address of 
said ACK packet to said second IP address, at said second BTCP module : . . .and sending a 
handoff acknowledgmenl message to said first BTCP module " (emphasis added). Further, 
Anerousis does not appear to be relied upon in the rejection of claim 13 as disclosing these 
elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 13 be 
overturned. 
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Dependent Claims 14-15 

Claims 1 4- 1 5 each depend from claim 1 3, which depends from claim 1 1 . Thus, 
claims 14 and 15 each inherit all elements of claims 1 1 and 13, and are therefore allowable 
over Alheti in view of Amrousis at least for the reasons discussed above with claims 1 1 and 
13. Therefore, Appellant respectfully requests that the rejection of claims 14 and 15 be 
overturned. 

Dependent Claim 16 

Claim 16 depends from claim 13, which depends from claim 1 1, and thus claim 16 
inherits all elements of claims 1 1 and 13. Accordingly, claim 1 6 is allowable over Albert in 
view of Anerousis at least for the reasons discussed above with claims 1 1 and 13. 
Additionally, claim 16 ftirther recites: 

The method as described in Claim 13, comprising the further steps of 
intercepting a connection indication message sent from said first TCP 
module to an application layer above said first TCP module at a first upper- 
TCP (UTCP) module, said connection indication message sent by said first 
TCP module upon estabHshing said communication session; and 

holding said connection indication message at said first UTCP module. 

The combination oi Albert m view of Auerousis fails to disclose all of the further 
elements of claim 1 6. The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 1 6, as the reasoning for rejecting clai m 16 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 16 was rejected as being 
anticipated by Albert). However, Albert fails to disclose all elements of claim 16. For 
instance, Albert fails to teach at leasi the recited first upper TCP (UTCP) module. Further, 
Anerousis docs not appear to be relied upon in the rejection of claim 16 as disclosing these 
elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 16 be 
overturned. 

Dependent Claim 17 
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Claim 17 depends from claim 16, which depends from claim 13 which depends from 
claim 1 1, and thus claim 17 inherits all elements of claims 11, 13, and 16, Accordingly, 
claim 17 is allowable ovtr Albert in view otAneroims at least for the reasons discussed 
above with claims 1 1, 13, and 16. Additionally^ claim 17 further recites: 

The method as described in Claim 16, wherein step h) comprises the 
further steps of: 

sending a reset packet from said first BTCP module upon receiving 
said handoff acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP 
module; 

receiving incoming data packets from said client at said first BTCP 

module; 

changing said destination addresses of said incoming daia packets to 
said second IP address; 

updating sequence numbers and TCP checksum in said data packets to 
reflect said second TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

The combination oi Albert in view of Anerousis fails to disclose all of the further 
elements of claim 1 7. The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 17, as the reasoning for rejecting claim 17 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 17 was rejected as being 
anticipated by Albert). However, Albert fails to disclose all elements of claim 1 7. For 
instance, Albert fails to teach at least the recited **sending a reset packet from said first BTCP 
module upon receiving said handoff acknowledgment packet to said first TCP module". 
Further, Anerousis does not appear to be relied upon in the rejection of claim 17 as disclosing 
these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 17 be 
overturned. 
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Dependent Claim 18 

Claim 1 8 depends from claim 1 1 and thus inherits all elements of claim 11. 
Accordingly* claim 18 is allowable over Albert in \ne\v Anerousis at least for the reasons 
discussed above with claim 1 1 . Additionally, claim 1 8 further recites: 

The method as described in Claim 1 1 , wherein step k) comprises the 
steps of: 

intercepting outgoing response packets from said selected server 
computer at said second BTCP module; 

changing soui-ce addresses of said response packets to said first IP 
address; 

updating sequence numbers and TCP checksum in said response 
packets to reflect said first TCP state of said first server computer; and 
sending said updated ne^onse packets to said client.. 

The combination of Albert in view ofAnerousis fails to disclose all of the further 
elements of claim 1 8. The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 1 8, as the reasoning for rejecting claim 1 8 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 18 was rejected as being 
anticipated by Albert). However, Albert fails to disclose all elements of claim 1 8. For 
instance, Albert fails to teach at least the recited "intercepting outgoing response packets from 
said selected server computer at said second BTCP module". Further, Aneroims does not 
appear to be relied upon in the rejection of claim 18 as disclosing these elements, nor does it 
do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 18 be 
overturned. 
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Dependent Claim 19 

Claim 19 depends from claim 1 1 and thus inherits all elements of claim 1 1. 
Accordingly, claim 19 is allowable over Albert in view of Anerousis at least for the reasons 
discussed above with claim 11. Additionally, claim 19 further recites: 

The method as described in Claim 1 1 , wherein step 1 ) comprises the 
steps of: 

monitoring TCP/IP control traffic for said communication session at 
said second BTCP module; 

understanding when said communication session is closed at said 
second server computer; 

sending a termination message to said first server computer over said 
control channel; 

terminating a forwarding mode ai said first BTCP module; and 

freeing data resources associated with said communication session at 
said first server computer. 

The combination of Albert in view of Anerousis fails to disclose all of the further 
elements of claim 19. The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 1 9, as the reasoning for rejecting claim 19 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 19 was rejected as being 
anticipated by Albert), However, Albert fails to disclose all elements of claim 1 9. For 
instance, Albert fails to teach at leas! the recited '^monitoring TCP/IP control traffic for said 
communication session at said second BTCP module" and 'terminating a forwarding mode at 
said first BTCP module". Further, Anerousis does not appear to be relied upon in the 
rejection of claim 19 as disclosing these elemems, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 19 be 
overturned. 
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Dependent Claim 20 

Claim 20 depends from claim 16, which depends from claim 13 which depends from 
claim 1 i, and thus claim 20 inherits all elements of claims 11, 13, and 16. Accordingly, 
claim 20 is allowable over Alberi in view of Auerousis at least for the reasons discussed 
above with claims 11,13, and 16. Additionally, claim 20 ftirther recites: 

The method as described in Claim 16, comprising the further steps of: 
sending notification from said first BTCP module to said first UTCP 

module to release said connection indication message, if said selected server 

computer is said first server computer; and 

sending incoming data packets, including said web request, from said 

client received at said first BTCP module, upstream. 

The combination o{ Albert in view of Auerousis fails to disclose all of the further 
elements of claim 20. The Office action of April 30, 2008 appears to rely upon AibeN as 
disclosing all elements of claim 20, as the reasoning for rejecting claim 20 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 20 was rejected as being 
anticipated by Albert), However, Alberi fails to disclose all elements of claim 20. For 
instance, Albert fails to teach at least the recited "sending notification from said first BTCP 
module to said first UTCP module to release said connection indication message, if said 
selected server computer is said first server computer". Further, Anerousis does not appear to 
be relied upon in the rej^tion of claim 20 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 20 be 
overturned, 

Dependent Claim 21 

Claim 21 depends from claim 1 1 and thus inherits all elements of claim 11. 
Accordingly, claim 21 is allowable ovqx Albert in view of Anerousis at least for the reasons 
discussed above with claim 1 1 . Additionally, claim 21 further recites; 

The method as described in Claim 1 1 , wherein each of said plurality of 
server computers is constructed similarly including BTCP modules located 
downstream from TCP modules, and UTCP modules located upstream from 
TCP modules. 
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The combination of Albert in view of Anerousis fails to disclose all of the further 
elements of claim 21 . The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 2 1 , as the reasoning for rejecting claim 2 1 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 21 was rejected as being 
anticipated by Albert). However, Albert fails to disclose all elements of claim 21 . For 
instance. Albert fails to teach each of its server computers include BTCP modules located 
downstream from TCP modules, and UTCP modules located upstream from TCP modules. 
Again, Alheh fails to teach the recited BTCP and UTCP modules. Further, Anerousis does 
not appear to be relied upon in the rejection of claim 21 as disclosing these elements, nor 
does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 2 1 be 
overturned. 

Dependent Claim 22 

Claim 22 depends from claim 12, which depends from claim 1 1. 'ITius, claim 22 
inherits all elements of claims 1 1 and 12, and are therefore allowable ovtr Albert in view of 
Anerousis at least for the reasons discussed above with claims 1 1 and 12. Therefore, 
Appellant respectfully requests that the rejection of claim 22 be overturned. 

Depeadeot Claim 23 

Claim 23 depends from claim 22, which depends from claim 12 which depends from 
claim 1 1. Thus, claim 23 inherits all elements of claims 11,12, and 22. Accordingly, claim 
23 is allowable over Albert in view of Anerousis at least for the reasons discussed above with 
claims 11, 12, and 22. Additionally, claim 23 further recites: 

The method as described in Claim 22, wherein said control channel 
allows for communication between all UTCP modules. 

The combination Albert in view of Anerousis fails to disclose all of the further 
elements of claim 23, The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 23, as the reasoning for rejecting claim 23 appears to be the 
same as in the Final Office Action of April 20r2005"(in which claim 23'was rejected as" 
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anticipated by Albert). However, Albert fails to disclose all elements of claiin 23. For 
instance, Albert fails to teach each UTCP modules, and thus fails to teach a control channel 
that allows communication between all of such UTCP modules. Further, Anerousis does not 
appear to be relied upon in the rejection of claim 23 as disclosing these elements, nor does it 
do so. 

Accordingly, Appellant respectfully requests that tlie rejection of claim 23 be 
overturned. 

Dependent Claims 24-25 

Claims 24-25 each depend from claim 1 1 , and thus claims 24 and 25 each inherit all 
elements of claim 1 1 . Therefore, claims 24-25 are each allowable over^/A^r/ in view of 
Anerousis at least for the reasons discussed above with claim 11. As such, Appellant 
respectfully requests that the rejecrion of claims 24 and 25 be overturned. 

Dependent Claim 27 

Claim 27 depends from claim 26 and thus inherits all elements of claim 26. 
Accordingly, claim 27 is allowable over Albert in view of Anerousis at least for the reasons 
discussed above with claim 26. Additionally, claim 27 further recites: 

The server computer as described in Claim 26, wherein said method 
comprises the steps of: 

a) establishing a TCP/IP communication session between a client 
computer and said server computer, said first node, said server computer part 
of a plurality of server computers forming said cluster network containing 
information, said communication session established for the transfer of data 
contained within said information; 

b) receiving a web request associated with said TCP/IP 
communication session at a first BTCP module at said server computer; 

c) examining content of said web request : 

d) determining which of said plurality of server computers, a 
selected server computer, can best process said web request, based on said 
content : 

e) handina off said communication session to said selected server 
computer from said server computer over a persistent contTol channel , if said 
selected server computer is not said server computer; and 

f) migrating a first TCP state of said server computer to said 
selected server computer, and sending a second TCP state of said selected 
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server computer to said server computer over said control channel, (Emphasis 
added). 

The combination of Albert in view o(Anerousis fails to disclose all of the further 
elements of claim 27, The Office action of April 30, 2008 appears to rely upon Albert 'd^s 
disclosing all elements of claim 27, as the reasoning for rejecting claim 27 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 27 was rejected as being 
anticipated by Alberi), However, Albert fails to disclose all elements of claim 27. For 
instance, as discussed above with claim 1 1, Albert fails to teach determining which of the 
plurality of server computers, a selected server computer, can best process a web request, 
based on content of the web request. As also discussed above with claim 1 1 , Albert fails to 
teach handing of a communication session over a persistent control channel. Furtter, 
Anerousis does not appear to be relied upon in the rejection of claim 27 as disclosing these 
elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 27 be 
overturned. 

Dependent Claim 28 

Claim 28 depends from claim 27, which depends from claim 26, and thus claim 28 
inherits all elements of claims 26 and 27. Accordingly, claim 28 is allowable over Albert in 
view of Anerousis at least for the reasons discussed above with claims 26 and 27. 
Additionally, claim 28 further recites; 

The ser\'er computer as described in Claim 27, wherein step a) of said 
method comprises the steps of: 

receiving a SYN packet from said client at said BTCP module; 

sending said SYN packet upstream to said TCP module; 

receiving a first SYN/ACK packet from said TCP module; 

parsing a first initial TCP state from said first SYN/ACK packet, 
including a first initial sequence number for said TCP module associated with 
said TCP/IP communication session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said BTCP module; 

sending said ACK packet to said TCP module; 

storing said SYN, ACK at said server computer. 
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The combination of Albert in view of Auerousis fails to disclose all of the ftirther 
elements of claim 28. The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 28, as the reasoning for rejecting claim 28 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 28 was rejected as being 
anticipated by Albert), However, Albert fails to disclose all elements of claim 28. For 
instance, as discussed above, Albert fails to teach the BTCP module, and thus for at least this 
reason Albert fails to teach the above steps that involve such BTCP module. Further, 
Anerousis docs not appear to be relied upon in the rejection of claim 28 as disclosing these 
elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 28 be 
overturned. 

Dependent Claim 29 

Claim 29 depends from claim 28, which depends from claim 27 which depends from 
claim 26, and thus claim 29 inherits all elements of claims 26-28. Accordingly, claim 29 is 
allowable over Albert in view ofAmrousis at least for the reasons discussed above with 
claims 26-28. Additionally, claim 29 further recites: 

The server computer as described in Claim 28, wherein said method 
comprises the steps of: 

sending a handoff request packet from said BTCP module to a second 
BTCP module over said control channel, said second BTCP module located 
below a second TCP module in a second operating system at said selected 
server computer; 

including said SYN packet and said ACK packet in said handoff 
request; 

receiving a handoff acknowledgment message at said BTCP module 
from said second BTCP module. 

The combination of Albert in view of Aneronsis fails to disclose all of the further 
elements of claim 29. The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 29, as the reasoning for rejecting claim 29 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 29 was rejected as being 
anticipated by Albert), However, Albert fails to disclose all elements of claim 29. For 
instance, as discussed'above, y4/ierr fails to teach the recited BTCP modules, and thus for at 
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least this reason Albert fails to teach the above steps that involve such BTCP modules. 
Further, Anewusis does not appear to be relied upon in the rejection of claim 29 as disclosing 
these elemenis, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 29 be 
overturned. 

Dependent Claim 30 

Claim 30 depends from claim 29, which depends from claim 28 which depends from 
claim 27 which depends from claim 26, and thus claim 30 inherits all elements of claims 26- 
29. Accordingly, claim 30 is allowable over Albert in view of Auerousis at least for the 
reasons discussed above with claims 26-29. Additionally, claim 30 further recites: 

The server computer as described in Claim 29, wherein said step f) of 
said method comprises the steps of: 

monitoring traffic associated with establishing said TCP/IP 
communication session in step a), at said BTCP module, to parse a first initial 
TCP state of said server computer, said first initial TCP state associated with 
said TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over 
said control channel by including said first initial TCP state in said IiandofT 
request, said first initial TCP state including a first sequence number, such that 
said second BTCP module can calculate said first TCP state for said server 
computer in said TCP/IP communication session. 

The combination of v4/ier/ in view of Amrousis fails to disclose all of the forther 
elements of claim 30. The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 30, as the reasoning for rejecting claim 30 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 30 was rejected as being 
anticipated by Albert). However, Albert fails to disclose all elements of claim 30. For 
instance, as discussed above, Albert fails to teach the recited BTCP module and control 
channel, and thus for at least these reasons Albert fails to teach the above steps that involve 
such BTCP modules and control channel. Further, Anerousis does not appear to be relied 
upon in the rejection of claim 30 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 30 be 
overturned. 
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Dependent Claim 31 

Claim 31 depends from claim 29, which depends From claim 28 which depends from 
claim 27 which depends from claim 26, and thus claim 31 inherits all elements of claims 26- 
29. Accordingly, claim 31 is allowable over Albert in view of Afierousis at least for the 
reasons discussed above with claims 26-29. Additionally, claim 31 further recites: 

The server computer as described in Claim 29, wherein said method 
comprises the further steps of: 

intercepting a connection indication message sent from said first TCP 
module to an application layer above said first TCP module at a first upper- 
TCP (UTCP) module, said connection indication message sent by said first 
TCP module upon establishing said communication session; and 

holding said connection indication message at said first UTCP module. 

The combination of Albert in view of Anerousis fails to disclose all of the further 
elements of claim 3 1 . The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 31, as the reasoning for rejecting claim 31 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 31 was rejected as being 
anticipated by Albert). However, Albert fails to disclose all elements of claim 3 1 . For 
instance. Albert fails to teach the recited first upper TCP (UTCP) module, and thus for at least 
this reason Albert fails to teach the above steps that involve such UTCP module. Further, 
Anerousis does not appear to be relied upon in the rejection of claim 31 as disclosing these 
elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 3 1 be 
overtuined. 
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Depepdent Claiin 32 

Claim 32 depends from claim 31, which depends from claim 29 which depends from 
claim 28 which depends from claim 27 which depends from claim 26, and thus claim 32 
inherits all elements of claims 26-29 and 3L Accordingly, claim 32 is allowable over Albert 
in view ofAnerousis at least for the reasons discussed above with claims 26-29 and 3 1 . 
Additionally, claim 32 flirther recites: 

The computer system as described in Claim 31, wherein said method 
comprises the further steps of: 

sending a reset packet froiii said first BTCP module upon receiving 
said handoff acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP 
module; 

receiving incoming data packets from said client at said first BTCP 
module; 

changing said destination addresses of said incoming data packets to 
said second IP address; 

updating sequence numbers and TCP checksum in said data packets to 
reflect said second TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

The combination of Albert in view of Amrousis fails to disclose all of the further 
elements of claim 32. The-Ofiice action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 32, as the reasoning for rejecting claim 32 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 32 was rejected as being 
anticipated by Albert), However, Albert fails to disclose all elements of claim 32. For 
instance, Albert fails to teach the recited ^'sending a reset packet from said first BTCP module 
upon receiving said handoff acknowledgment packet to said first TCP module" and 
^'discarding said connection indication message at said first UTCP module". Further, 
Aneroims dots not appear to be relied upon in the rejection of claim 32 as disclosing these 
elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 32 be 
overturned. 
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Dependent Claim 33 

Claiin 33 depends from claim 31, which depends from claim 29 which depends from 
claim 28 which depends From claim 27 which depends from claim 26, and thus claim 33 
inherits all elements of claims 26-29 and 3 1 . Accordingly, claim 33 is allowable over Albert 
in view of Anerousis at least, for the reasons discussed above with claims 26-29 and 31. 
Additionally, claim 33 further recites: 

The server computer as described in Claim 31, said method comprising 
the further steps of: 

sending notification from said BTCP module to said UTCP module to 
release said connection indication message, if said selected server computer is 
said server computer; 

sending incoming data packets, including said web request, from said 
client, received a! said first BTCP module, upstream. 

The combination of Albert in view of Amromis fails to disclose all of the further 
elements of claim 33. The Office action of April 30. 2008 appears to rely upon Albert as 
disclosing all elements of claim 33, as the reasoning for rejecting claim 33 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 33 was rejected as being 
anticipated by Albert). However, Albert fails to disclose all elements of claim 33. For 
instance, Albert fails to teach the recited BTCP and UTCP modules, and thus for at least this 
reason Albert fails to teach the above steps involving such modules^ Fntthety Anerousis does 
not appear to be relied upon in the rejection of claim 33 as disclosing these elements, nor 
does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 33 be 
overturned. 
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Dependent Claim 34 

Claim 34 depends from claim 26, and thus inherits all elements of claim 26. 
Accordingly, claim 34 is allowable over Albert in view of Anerousis at least for the reasons 
discussed above with claim 26. Additionally, claim 34 further recites: 

The server computer as described in Claim 26, said method comprising 
the further steps of: 

receiving a handoff request from a first BTCP module located at a first 
server computer within said cluster network over a persistent control channel, 
said First server computer having established a communication session with a 
client computer, said communication session established for the transfer of 
data contained within said server computer, said handoff request including a 
SYN packet and an ACK packet, said S YN and ACK packet used for 
establishing said communication session between said client and said first 
server computer, said ACK packet including a first initial TCP state of said 
first server computer in said communication session, including a first initial 
TCP sequence number, 

changing a first destination IP address of said SYN packet to a second 
IP address of said server computer, at said BTCP module; 

sending said SYN packet to said TCP module; 

receiving a SYN/ACK packet at said second BTCP module; 

parsing a second initial TCP state from second SYN/ACK packet, 
including a second initial sequence number, for said TCP module, said second 
initial TCP state associated with a second TCP state for said server computer 
in said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said 
second IP address, at said BTCP module; 

updating said ACK packet to reflect said second TCP state of said 
selected server computer in said communication session; 

sending said ACK packet that is updated to ^id TCP module; and 

sending a handoff acknowledgment message to said first BTCP 
module over said control channel. 

The combination of Albert in view of Amrousis fails to disclose all of the further 
elements of claim 34, The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 34, as the reasoning for rejecting claim 34 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 34 was rejected as being 
anticipated by Albert), However, Albert fails to disclose all elements of claim 34, For 
instance, Albert fails to teach at least the recited *Veceiving a handoff request firom a first 
BTCP module located at a first server computer within said cluster network over a persistent 
control channel". As discussed.above with claim ! 1, Albert Mis iode^ch zInsl BXCP „ 
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module or a persistent control channel. Further, ^//?6^/V fails to teach a **handoff request**. 
Rather, Alheh merely teaches that its forwarding agents forward packe(s to a selected back- 
end server, rather than handing off the TCP communication session. Further, Anerousis does 
not appear to be relied upon in the rejection of claim 34 as disclosing these elements, nor 
does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 34 be 
overturned. 

Dependent Claim 35 

Claim 35 depends from claim 34, which depends from claim 26, and thus claim 35 
inherits all elements of claims 26 and 34. Accordingly, claim 35 is allowable over Albert in 
view of Anerousis at least for the reasons discussed above with claims 26 and 34. 
Additionally, claim 35 further recites: 

The serv^er computer as described in Claim 34, wherein said method 
comprises the further steps of: 

monitoring traffic associated with handing off said TCP/IP 
communication session to said server computer, at said BTCP module, to 
parse said second initial TCP state of said server computer, said second initial 
TCP state associated with said TCP/IP communication session; and 

sending said second initial TCP state of said server computer to said 
first BTCP module by including said second initial TCP state in said handoff 
acknowledgment, said second initial TCP state including a second initial 
sequence number, such that said first WVO? module can calculate said second 
TCP state for said server computer in said TCP/IP communication session. 

The combination of Albert in view of Anerousis fails to disclose all of the further 
elements of claim 35. The Office action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 35, as the reasoning for rejecting claim 35 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 35 was rejected as being 
anticipated by Albert), However, Albert fails to disclose all elements of claim 35. For 
instance, Albert fails to teach at least the recited BTCP module, thus for at least this reason 
Albert fails to teach the above steps that involve such BTCP module. Further, Anerousis does 
not appear to be relied upon in the rejection of claim 35 as disclosing these elements, nor 
does it do so. 
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Accordingly, Appellant respectfully requests that the rejection of claim 35 be 
overturned. 

Dependent Claim 36 

Claim 36 depends from claim 34, which depends from claim 26, and thus claim 36 
inherits all elements of claims 26 and 34. Accordingly, claim 36 is allowable over Albert in 
view ofAuerousis at least for the reasons discussed above with claims 26 and 34, 
Additionally, claim 36 further recites: 

The server computer as described in Claim 34, wherein said method 
comprises the further steps of: 

intercepting outgoing response packets from said server computer at 
said second BTCP module; 

changing source addresses of said response packets to said first IP 
address; 

updating sequence numbers and TCP checksum in said response 
packets to reflect said first TCP state of said first server computer; and 
sending said response packets to said client. 

The combination of Albert in view of Amronsis fails to disclose all of the further 
elements of claim 36, The Office action of April 30, 2008 appears to rely npon Albert as 
disclosing all elements of claim 36, as the reasoning for rejecting claim 36 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 36 was rejected as being 
anticipated by Albert). However, Albert fails to disclose all elements of claim 36. For 
instance, Albert fails to teach at least the recited second BTCP module, thus for at least this 
reason Albert fails to teach the above intercepting step that involves such second BTCP 
module. Further, Auerousis does not appear to be relied upon in the rejection of claim 36 as 
disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 36 be 
overturned. 
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Dependent Claim 37 

Claim 37 depends from claim 34, which depends from claim 26, and thus claim 37 
inherits all elements of claims 26 and 34. Accordingly, claim 37 is allowable ovtx Albert in 
view of Anerousis at least for the reasons discussed above with claims 26 and 34. 
Additionally, claim 37 further recites: 

The server computer as described in Claim 34, wherein said method 
comprises the funher steps of; 

monitoring TCP/IP control traffic for said communication session at 
said BTCP module; 

understanding when said communication session is closed at said 
server computer; and 

sending a termination message to said first server computer over said 
control channel. 

The combination of Albert in view of Anerousis fails to disclose all of the further 
elements of claim 37. The Office Action of April 30, 2008 appears to rely upon Albert as 
disclosing all elements of claim 37, as the reasoning for rejecting claim 37 appears to be the 
same as in the Final Office Action of April 20, 2005 (in which claim 37 was rejected as being 
anticipated by Albert). However, Albert fails to disclose all elements of claim 37. For 
instance, Albert fails to teach at least the recited BTCP module and control channel, and thus 
fails to teach the above steps that involve such BTCP module and control channel. Further, 
Anerousis does not appear to be relied upon in the rejection of claim 37 as disclosing these 
elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 37 be 
overturned. 
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VIII. CLAIMS 

A copy of the claims involved. in the present appeal is attached hereto as Appendix A. 

IX, EVIDENCE 

No evidence pursuant to§§ 1.130, 1.131, or 1,132 or entered by or relied upon by the 
examiner is being submitted. 

X RELATED PROCEEDINGS 

No related proceedings are referenced in IL above, or copies of decisions in related 
proceedings are not provided, hence no Appendix is included. 

CONCLUSION 

It is respectfully requested that the Board reverse the final rejection of claims 1-37 
under 35 U,S.C.§ 103(a). 



Respectfully submitted, 



Wcnting Tang et al. 





Eileen Lehmann 
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APPENDIX A 

Claims Involved in the Appeal of Application Serial No. 09/880,631 

1 . In a communication nelAVork, a method of TCP slate migration comprising the 
steps of: 

a) establishing a TCP/IP communication session between a client computer and a 
first server computer, said first server computer part of a plurality of server computers 
forming a web cluster containing information, said communication session established for the 
transfer of data contained within said information; 

b) handing off said communication session to a selected server computer from 
said first server computer over a persistent control channel using TCP liandofT modules that 
are dynamically loadable within TCP/IP stacks in operating systems located at both said first 
server computer and said selected server computer, that implement a TCP handoff protocol 
that works within kernel levels of an existing TCP/IP protocol; and 

c) migrating a first TCP state of said first server computer to said selected server 
computer, and a second TCP state of said selected ser\'er computer to said first server 
computer over said control channel. 

2. The method as described in Claim 1 , wherein said step a) comprises the steps 

of: 

receiving a SYN packet from said client at a first BTCP module located at said first 
server computer; 

sending said SYN packet upstream to a iirst TCP module located above said first 
BTCP module in a first operating system of said first server computer; 

receiving a first SYN/ACK packet from said first TCP module; 

parsing said first initial TCP state from said first SYN/ACK packet, including a first 
initial sequence number for said first TCP module associated with said TCP/IP 
communication session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said first BTCP module; 

sending said ACK packet to said first TCP module; 

receivmg a webjeguesj packet associated with said TCP/IP communication session at 
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said first BTCP module at said first server computer; 

storing said SYN, ACK and said web request packet at said first server computer. 

3. The method as described in Claim 2, wherein said step b) comprises the steps 

of; 

examining content of said web request packet; 

determining which of said plurality of server computers, a selected server computer, 
can best process said WEB request packet, based on said content; 

sending a handoff request from said first BTCP module to a second BTCP module at 
said selected server computer over said control channel, if said selected server computer is 
not said first server computer; 

including said SYN packet and said ACK packet in said handoff request packet; 

changing a first destination IP address of said SYN packet to a second IP address of 
said selected server computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second SYN/ ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ACK packet, including a 
second initial sequence number, for said second TCP module, that is associated with said 
TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said second IP 
address, at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected server 
computer in said communication session; 

sending said ACK packet that is updated to said second TCP module; and 

sending a handoff acknowledgment message to said first BTCP module. 

4. The method as described in Claim 3, wherein step c) comprises the steps of: 
monitoring traffic associated with establishing said TCP/IP communication session in 

step a), at said first BTCP module, to parse a first initial TCP state of said first sender 
computer, said first initial TCP state associated with said TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over said control 
channel by including said first initial TCP state in said handoff request packet, said first 
initial TCP.stateincluding a first sequence number, such that said second. BTCP module.can 
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calculate said first TCP state for said first server computer in said TCP/IP commuiiication 
session. 

5. The method as described in Claim 3, wherein step c) comprises the steps of: 
monitoring traffic associated with handing off said TCP/IP communication session at 

said second BTCP module, to parse a second initial TCP state of said selected server 
computer, said second initial TCP state associated with said TCP/IP communication session; 
and 

migrating said second initial TCP state of said selected server computer to said first 
BTCP module by including said second initial TCP state in said handoff acknowledgment 
packet, said second initial TCP state including a second initial sequence number, such that 
said first BTCP module can calculate said second TCP state for said selected server computer 
in said TCP/IP communication session, 

6. The method as described in Claim 2, coinprising the funher steps of: 
intercepting a connection indication message sent from said first TCP module to an 

application layer above said first TCP module at a first upper-TCP (UTCP) module, said 
connection indication message sent by said first TCP module upon establishing said 
communication session; and 

holding said connection indication message at said first UTCP modulo. 

7. The method as described in Claim 6, wherein said method comprises the 
further steps of; 

sending a reset packet firom said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 

receiving incoming data packets from said client at said first BTCP module; 

changing said destination addresses of said incoming data packets to said second IP 
address; 

updating sequence numbers and TCP checksum in said data packets to reflect said 
second TCP stale of said selected server computer; and 

forwarding said data packets to said selected server computer. 
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8. The method as described in Claim 6, comprising the further steps of: 
sending notification from said first BTCP module to said first UTCP module to 

release said connection indication message, if said selected server computer is said first 
server computer; 

sending incoming data packets, including said web request packet, from said client, 
received at said first BTCP module^ upstream. 

9. The method as described in Claim I, comprising the further step of: 
intercepting outgoing response packets from said selected server computer at a second 

bottom TCP (BTCP) module located at said selected server computer; 

changing source addresses of said response packets to a first IP address of said fii^st 
server computer; 

updating sequence numbers and TCP checksum in said response packets to reflect 
said first TCP state of said first server computer; and 
sending said response packets to said client. 

10. The method as described in Claim 1 , comprising the further steps of: 
monitoring TCP/IP control traffic for said communication session at said second 

BTCP module; 

understanding when said communication session is closed at said second server 
computer; 

sending a termination message to said first server computer over said control channel; 

terminating said TCP/IP communication session at said first server computer by 
terminating a forwarding mode at said first BTCP module; and 

freeing data resources associated with said communication session at said first server 
computer. 

11. In a communication network, a method of TCP state migration comprising the 
steps of: 

a) establishing a TCP/IP communication session between a client computer and a 
first server computer, said first server computer part of a plurality of server computers 
forming a web cluster containing information, said communication session established for the 
transfer of data contained within said infoimation; 

b) monitoring traffic associated with establishing said TCP/IP communication 
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session to understand a fim initial TCP state of said first sen'cr computer associated with 
said TCP/IP communication session, at a first bottom-TCP (BTCP) module at said first server 
computer; 

c) receiving a web request associated with said TCP/IP communication session at 
said first BTCP module at said first server computer; 

d) examining content of said web request; 

e) determining which of said plurality of server computers, a selected server 
computer, can best process said web request, based on said content; 

0 handing off said communication session to said selected server computer from 
said first server computer over a persistent control channel, if said selected server computer is 
not said first server computer; 

g) monitoring traffic as^ciated with handing off said TCP/IP communication 
session to understand a second initial TCP state of said selected server computer associated 
with said TCP/IP communication sessiorii at a second BTCP module at said selected server 
computer; 

h) migrating said first initial TCP state to said selected server computer over said 
control channel, such that said second BTCP module can calculate a first TCP state for said 
first server computer in said TCP/IP communication session; 

i) sending a second initial TCP state of said selected server computer ^o said first 
BTCP module, such that said first BTCP module can calculate a second TCP state for said 
selected server computer in said TCP/IP communication session; 

j) forwarding data packets received at said first BTCP module from said client to 
said selected server computer, by changing said data packets to reflect said second TCP state 
and a second IP address of said selected server computer, 

k) sending response packets Irom said selected server computer directly to said 
client computer by changing said response packets to reflect said first TCP state and a first IP 
address of said first server computer; and 

1) terminating said TCP/IP communication session at said first server computer 
when said TCP/IP communication session is closed. 

12. The method as described in Claim 1 1 , wherein said step a) comprises the steps 

of: 

receiving a packef fi^^ 
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sending said SYN packet upstream to a first TCP module located above said first 
BTCP module in a first operating system of said first server computer; 

receiving a first SYN/ACK packet from said first TCP module; 

parsing said first initial TCP state from said first SYN/ACK packet, including a first 
initial sequence number for said first TCP module associated with, said TCP/IP 
communication session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said first BTCP module; 

sending said ACK packet to said first TCP module; 

storing said SYN, ACK and said web request at said first server computer. 

13. The method as described in Claim 1 1 , wherein said step e) comprises the steps 

of: 

sending a handofT request packet from said first BTCP module to said second BTCP 
module over said control channel; 

including said SYN packet and said ACK packet in said handofi' request packet; 

changing a first destination IP address of said SYN packet to a second IP address of 
said selected server computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second SYN/ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ACK packet, including a 
second initial sequence raimber, for said second TCP module, that is associated with said 
TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said second IP 
address, at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected server 
computer in said communication session; 

sending said ACK packet that is updated to said second TCP module; and 

sending a handoff acknowledgment message to said first BTCP module. 
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14. The method as described in Claim 13, wherein said ACK packet includes said 
first initial TCP state of ^id first server computer as provided for in step 0- 

15. The method as described in Claim 13, wherein said handoff acknowledgment 
includes said second initial TCP state of said second server computer, including a second 
initial sequence number, for said second TCP module, that is associated with said TCP/IP 
communication session as provided for in step i). 

16. The method as described in Claim 13, comprising the further steps of: 
intercepting a connection indication message sent from said first TCP module to an 

application layer above said first TCP module al a first upper-TCP {UTX;;P) module, said 
connection indication message sent by said first TCP module upon establishing said 
communication session; and 

holding said connection indication message at said first UTCP module. 

1 7. The method as described in Claim 1 6, wherein step h) comprises the further 
steps of: 

sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module; 

discatding said connection indication message at said first UTCP module; 

receiving incoming data packets from said client at said first BTCP module; 

changing said destination addresses of said incoming data packets to said second IP 
address; 

updating sequence numbers and TCP checksum in said data packets to reflect said 
second TCP state of said selected server computer; and 

forwarding said data packets to said selected sender computer. 

18. The method as described in Claim 1 1 , wherein step k) comprises the steps of: 
intercepting outgoing response packets from said selected server computer at said 

second BTCP module; 

chan^ng source addresses of said response packets to said first IP address; * 
updating sequence numbers and TCP checksum in said response packets to reflect 

said first TCP state of sakl first server computer; and 

sending'said updated response packets to said client. 
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19. The method as described in Claim 1 1 , wherein step 1) comprises the steps of: 
monitoring TCP/IP control traffic for said communication session at said second 

BTCP module; 

understanding when said communication session is closed at said second server 
computer; 

sending a termination message to said first server computer over said control channel; 
terminating a forwarding mode at said first BTCP module; and 
freeing data resources associated with said communication session at said first server 
computer, 

20. Tlie method as described in Claim 16, comprising the further steps of: 
sending notification from said first BTCP module to said first UTCP module to 

release said connection indication message, if said selected server computer is said first 
server computer; and 

sending incoming data packets, including said web request, from said client, received 
at said first BTCP module, upstream. 

2 1 . The method as described in Claim 1 1 , wherein each of said plurality of server 
computers is constructed similarly including BTCP modules located downstream from TCP 
modules, and UTCP modules located upstream from TCP modules. 

22. The method as described in Claim 12, comprising the further step of storing 
said web request, said SYN packet, said ACK packet, and said web request at said first server 
computer. 

23. The method as described in Claim 22, wherein said control channel allows for 
communication between all UTCP modules. 

24. The method as described in Claim 1 1 , wherein said plurality of server 
computers is coupled together over a wide area network in said communication network. 

25. The method as described in Claim 1 1 , wherein said information is 
partitioned/partially replicated throughout each of said plurality of server computers. 
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26. A server computer comprising: 

an upper TCP (UTGP) module located above a TCP module in an operating system of 
said server com pu ter ; 

a bottom TCP (BTCP) module located below said TCP module, said UTCP, TCP, and 
BTCP modules implementing a method of handing off a communication session between a 
first node and second node in a cluster network that works within the kernel level of an 
existing TCP/IP protocol^ by migrating TCP states associated with said first and second 
nodes. 

27. The server computer as described in Claim 26, wherein said method comprises 
the steps of: 

a) establishing a TCP/IP communication session between a client computer and 
said server computer, said first node, said server computer part of a plurality of server 
computers fomiing said cluster network containing information, said communication session 
established for the transfer of data contained within said information; 

b) receiving a web request associated with said TCP/IP communication session at 
a first BTCP module at said server computer; 

c) examining content of said web request; 

d) determining which of said plurality of server computers, a selected server 
computer, can best process said web request, based on said content; 

e) handing off said communication session to said selected server computer from 
said server computer over a pei-sistent control channel, if said selected serx'er computer is not 
said server computer; and 

f) migrating a first TCP state of said server computer to said selected server 
computer, and sending a second TCP state of said selected server computer to said server 
computer over said control channel 

28. The server computer as described in Claim 27, wherein step a) of said method 
comprises the steps of: 

receiving a SYN packet from said client at said BTCP module; 
sending said SYN packet upstream to said TCP module; 
recei\nng a first SYN/ ACK packet from said TCP module; 
parsing a first initial TCP state from said first S YN/ACK packet, including a first 
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initial sequence number for said TCP module associated with said TCP/IP communication 
session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said BTCP module; 

sending said ACK packet to said TCP module; 

storing said SYN, ACK at said server computer 

29. The server computer as described in Claim 28, wherein said method comprises 
the steps of: 

sending a handoff request packet from said BTCP module to a second BTCP module 
over said control channel, said second BTCP module located below a second TCP module in 
a second operating system at said selected server computer; 

including said SYN packet and said ACK packet in said handoff request; 

receiving a handoff acknowledgment message at said BTCP module from said 
second BTCP module, 

30. The server computer as described in Claim 29, wherein said step f) of said 
method comprises the steps of: 

monitoring traffic associated with establishing said TCP/IP communication session in 
step a), at said BTCP module, to parse a first initial TCP state of said server computer, said 
first initial TCP state associated with said TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over said control 
channel by including said first initial TCP state in said handoff request, said first initial TCP 
state including a first sequence number, such that said second BTCP module can calculate 
said first TCP state for said server computer in said TCP/IP communication session. 

31 . The server computer as described in Claim 29, wherein said method comprises 
the further steps of: 

intercepting a connection indication message sent from said first TCP module to an 
application layer above said first TCP module at a first upper-TCP (UTCP) module, said 
connection indication message sent by said first TCP module upon estabHshing said 
communication session; and 

holding said connection indication message at said first UTCP module. 
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32. The computer system as described in Claim 31 , wherein said method 
comprises the further steps of: 

sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet lo said first TCP module; 

discarding said connection indication message at said first UTCP module; 

receivihg incoming data packets from said client at said first BTGP module; 

changing said destination addresses of said incoming data packets to said second IP 
address; 

updating sequence numbers and TCP checksum in said data packets to reflect said 
second TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

33. The server computer as described in Claim 31 , said method comprising the 
further steps of: 

« 

sending notification from said BTCP module to said UTCP module to release said 
connection indication message, if said selected server computer is said server computer; 

sending incoming data packets, including said web request, from said client, received 
at said first BTCP module, upstream. 

34. The server computer as described in Claim 26, said method comprising the 
further steps of: 

receiving a handoff request from a first BTCP module located at a first server 
computer within said cluster network over a persistent control channel, said first server 
computer having established a communication session with a client computer, said 
communication session established for the transfer of data contained within said server 
computer, said handoff request including a SYN packet and an ACK packet, said SYN and 
ACK packet used for establishing said communication session between said client and said 
first server computer, said ACK packet including a first initial TCP state of said first server 
computer in said communication session, including a first= initial TCP sequence number; 

changing a first destination IP address of said S VN packet to a second IP address of 
said server computer, at said BTCP module; 

sending said SYN packet to said TCP module; 

receiving a SYN/ACK packet at said second BTCP-module; 
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parsing a second initial TCP state from second SYN/ACK packet, including a second 
initial sequence number, for said TCP module, said second initial TCP state associated with a 
second TCP state for said server computer in said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said second IP 
address, at said BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected server 
computer in said communication session; 

sending said ACK packet that is updated to said TCP module; and 

sending a handoff acknowledgment message to said first BTCP module over said 
control chanf^l. 

35. The server computer as described in Claim 34, wherein said method comprises 
the further steps of: 

monitoring imffic associated with handing off said TCP/IP communication session to 
said server computer, at said BTCP module, to parse said sa^ond initial TCP state of said 
server computer, said second initial TCP state associated with said TCP/IP communication 
session; and 

sending said second initial TCP state of said server computer to said first BTCP 
module by including said second initial TCP state in said handoff acknowledgment, said 
second initial TCP state including a second initial sequence number, such that said first 
BTCP module can calculate said second TCP state for said sender computer in said TCP/IP 
communication session. 

36, The server computer as described in Claim 34, wherein said method comprises 
the further steps of: 

intercepting outgoing response packets from said server computer at said second 
BTCP module; 

changing source addresses of said response packets to said first IP address; 
updating sequence numbers and TCP checksum in said response packets to reflect 
said first TCP state of said first server computer; and 
sending said response packets to said client. 
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37, The server computer as described in Claim 34, wherein said method comprises 
the further steps of: 

monitoring TCP/IP control traffic for said communication session at said BTCP 
module; 

understanding when said communication session is closed at said server computer; 

and 

sending a termination message to said first server computer over said control channel. 
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